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The Customer Service Center (CSC) interface to the Transaction 
Network System (tns) is designed primarily for flexibility and effi- 
ciency so as to be able to interconnect with the majority of present 
customer computer installations. In addition, since these host com- 
puters have a large potential capability under program control, TNS 
features are made available, but are not generally mandated, to provide 
CSC control over and thereby optimize usage of this interface. This 
paper describes the design philosophy and the features of this inter- 
face. 

I. DESIGN CRITERIA 

The Transaction Network Service (TNS) is a new Bell System data 
offering to handle short data messages between Customer Service 
Centers (CSCs), e.g., host computers, and remote stations such as tele- 
phones, terminals, and other CSCs. An accompanying paper 1 describes 
the overall system design as depicted in Fig. 1; in this paper, the CSC 
interface is covered in detail. The CSC interface consists of a syn- 
chronous data link using the binary synchronous protocol. 

1. 1 Anticipated customer configuration 

Figure 2 shows a block diagram of a typical software and hardware 
configuration at the CSC. The actual configuration is dependent on the 
supplier of hardware or software. The basic features however, are always 
present and may be relocated (e.g., if a front-end processor is installed, 
then some access method functions take place in the front end) to other 
segments of hardware and/or software. 

The host computer software is generally operating under an operating 
system with several application programs resident for processing the 
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Fig. 1— Transaction Network. 

messages. These programs are written by the CSC's staff. To interface 
between these application programs and the data links (which are con- 
nected to the remote TNS), a telecommunication monitor is often 

used. 

Telecommunication monitors provide three basic functions: 

(i) A data base interface. 

(ii) Multi-threading (the capability of processing multiple messages 

in parallel) of application programs. 

A data link interface (drives the telecommunications access 

method) and the device-dependent characteristics of the far-end 

station. 
The first function depends solely on the processing programs, whereas 
the last two functions directly affect the CSC interconnection with 
TNS. 

1.2 Design statement 

The hardware for the data links has been specified according to 
standard industry practices to consist of four-wire, point-to-point, 
synchronous facilities operating at 2.4, 4.8, or 9.6 kb/s. 

The system design challenge then is not the physical connection of 
stations but instead is the passing of intelligence between two entities, 
namely, the TNS message switch and the CSC's application program. To 
accomplish this, protocols are specified which properly pass the intel- 
ligence over the data link and through the software and hardware to the 
application programs. 

These protocols are essentially a priori agreements between stations 
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Fig. 2 — Sample software configuration. 

which provide for communication procedures under normal conditions 
and correction of any errors or anomalies that may arise. 

1.3 Design criteria 

In providing the TNS protocol specification for CSCs, the basic as- 
sumption is that the major hardware and software elements are available 
and that all the CSC should be required to do is provide interface pro- 
grams (which can be written in a high-level language such as Cobol) 
between the CSC telecommunications monitor and the CSC's data base. 
Therefore, in selecting the features to be offered to CSCs, the following 
criteria are followed: 
(i) A single, universal interface to be compatible with all expected types 

of CSC installations. 
(ii) Minimum hardware/software impact on existing CSC installa- 
tions. 
(Hi) Simplicity of installation with extension to full capabilities. 
(iu) Efficient use of facilities and processing of messages. 
(u) Reliable, flexible, and maintainable service. 
The next sections describe briefly the features offered by TNS to achieve 
the above; complete descriptions are given in Refs. 2 and 3. Section II 
describes the overall network features; Section III, the data link protocol 
(DLP) and message format specification; Section IV, the options to 
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provide flexibility; Section V, status reports and service messages; and 
Section VI, a description of a system implemented to test the inter- 
face. 

II. NETWORK FEATURES 

TNS provides a set of features so that each individual CSC can establish 
a network to fit its individual requirements. These features consist of 
a group concept which provides one single logical address for several 
physical links, alternate delivery which provides for automatic rerouting 
of messages, and screening which allows the CSC to predetermine the 
stations with which it desires to communicate. 

2.1 Line group 

Complete control of the CSC network by TNS ends at the local TNS 
port. To provide redundancy on the interface, one-for-iV (N is the 
number of links utilizing identical data sets on a single message switch) 
sparing of message switch ports is provided. This spare port will be au- 
tomatically switched in to replace any failing port by the message 
switch. 

To further provide redundancy of both the data links and the CSC 
ports as well as greater traffic capacity, multiple data links may be in- 
corporated into a line group. The line group contains multiple physical 
paths under a single, logical TNS directory number. 

TNS will then distribute the message load that is transmitted to the 
CSC among all active lines in the line group and will accept messages from 
the CSC on any active line in the group. 

In addition to the single line group directory number used for call 
routing, each line in the line group is assigned a unique address for service 
message and maintenance purposes as discussed in Section V. 

2.2 Alternate delivery 

The line group concept provides increased traffic capabilities as well 
as hardware redundancy for a single CSC entity. If the primary CSC itself 
becomes unavailable due to exceeding its traffic capacity or due to outage 
of the entire CSC, an alternate delivery feature to a secondary CSC is 
available. This forwarding mechanism, if optioned, is automatically 
triggered when either the primary line group is not active or when the 
message queue to the CSC overflows. 

Forwarding a message consists of a single attempt to deliver to a sec- 
ondary line group with the message returned to the originator if both 
primary and secondary line groups are not available. A line group may 
provide alternate delivery for up to nine other line groups. 

Thus, alternate delivery provides an automatic alternate CSC for both 
scheduled or nonscheduled outages of an entire line group, and, as such, 
complements the line group concept. 
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2.3 Class of service 

TNS provides an automatic screening function based on the originator 
of a message: polled terminals, dial-in telephones, or other CSCs. This 
allows the CSC to receive messages from any station or only from pre- 
determined stations, e.g., the establishment of a private network within 

TNS. 

2.3. 1 Telephone and terminal classes of service 

A CSC may elect to communicate with any combination of the fol- 
lowing: 

(l) Dial-in telephones. 
(ii) Unrestricted polled terminals. 
(Hi) Restricted polled terminals. 
(iu) Other CSCs (affiliated or unaffiliated). 

Essentially, dial- in telephones consist of all stations originating calls 
over the Switched Telephone Network to the TNS dial-in interfaces. 2 
If this class of service is chosen, TNS will allow the CSC to both transmit 
to and receive from stations such as TOUCH-TONE 9 calling stations 
and Transaction I and Transaction II telephones. No further screening 
is available for dial-in stations, since TNS does not have control over 
originations on the Switched Telephone Network. 

For polled terminals, 2 completely dedicated TNS facilities are used 
to provide service and, consequently, the terminal's physical location 
is known: given this definite physical connectivity, it is useful that a 
terminal may be identified by TNS as being unrestricted and capable of 
communicating with any CSC specifying unrestricted class of service, 
or as being restricted and capable of communicating only with those CSCs 
(up to 10 for a shared private network) whose identity is stored in a TNS 
restricted service list. 

For CSC-to-CSC transfers, affiliated CSCs provide the logical equivalent 
of a private network for members of the affiliation. TNS verifies that the 
calling and called CSCs are members of the affiliation identified in the 
message, as provided by an affiliation list stored in TNS. A CSC identified 
as unaffiliated can receive messages from any other CSC provided the 
message is identified as unaffiliated. 

A Class of Service Character (CSCH) is used to accomplish these 
screening functions and is inserted by TNS for messages from a telephone 
or terminal or is provided by the CSC for messages between CSCs. Es- 
sentially, the range of the Class of Service Character identifies the station 
class and the value within the range identifies specific routing charac- 
teristics. 

All screening for the CSC uses the service classes elected by the pri- 
mary, not the alternate, delivery CSC, even when the message is delivered 
to the alternate CSC. 
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2.4 Example of network features 

Figure 3 depicts a group of three lines ordered by CSC A and a group 
of one line ordered by CSC B. The groups have group identification 
numbers for message routing of 5550012 for group A and 5550018 for 
group B, as identified by the dotted loops. Note that, for routing pur- 
poses, the three lines in CSC A's group are indistinguishable. If any one 
or more of the links become inoperative, all traffic is automatically routed 
to the remaining active lines in the group. Of course, no such protection 
exists for group B since it is a group of size one. 

In addition, each line within a group is assigned an identification 
number which for group A consists of the numbers 5550997, 5550998, 
and 5550986 and for group B is 5550990. These numbers are used for 
service messages and for line maintenance purposes. 

Also shown is an alternate delivery point for automatic forwarding 
from CSC A to CSC B, which will be used whenever either CSC A's group 
is not active or its queue temporarily overflows. 

III. INTERFACE SPECIFICATIONS 

The basic interface specifications are based on the referenced ANSI 

standards: 

(i) Data transfer its half-duplex under Binary Synchronous Com- 
munication (BCS) procedures. 4 

(ii ) Data link hardware is full duplex, including data set operation and 
4-wire facilities. 

{Hi) Seven-bit ASCII 5 is used for all data link control characters and all 
Bell System specified message heading entries which, with odd 
parity, 6 produces 8-bit (or one byte) characters. 

(iv) The least significant bit is transmitted first. 7 

(u) Message heading is based on proposed ANSI standard. 8 
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Fig. 3— Line group and alternate delivery. 
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3. 1 Data link protocol { DLP) description 

In Fig. 4, data link protocol procedures are broken into three parts: 
connection, data transfer with acknowledgments, and termination. 

Under a contention protocol, either party may bid for the link when 
it has messages to send. A bid consists of issuing an enquiry (enq) se- 
quence. In cases of simultaneous bids, one party is permanently desig- 
nated the primary and will rebid in 1 second, while the other is the sec- 
ondary and will rebid in 3 seconds. Upon successfully bidding for a line, 
as determined by receiving a positive acknowledgment (ACK 0), that 
station becomes the master station and the station which sent the pos- 
itive acknowledgment becomes the slave. The master station then starts 
sending blocks of messages which are acknowledged by alternating ac- 
knowledgments, ACK and ACK 1, from the slave station. This master/ 
slave status designation is dynamic and is reestablished upon each 
successful bid for the line. 

Upon completion, the master station relinquishes control of the line 
by sending the termination sequence (end of transmission sequence, 
EOT) and may not bid anew for the line for a post EOT delay of 1 or 3 
seconds. Within this post-EOT delay, the former slave station may bid 
for the line without any contention from the former master and can 
thereby become the master station without contention. 

After the post-EOT delay, either party may bid for the line and con- 
tention may occur. 

If a block becomes garbled, the slave station sends a negative ac- 
knowledgment (nak) and the master retransmits the block up to a 
predetermined maximum number of retries. 

One of the features of the data link protocol consists of the optional 
inclusion of the transmission of the WACK and RVI sequences as replies, 
where both are positive acknowledgments. The WACK sequence requests 
the master to temporarily halt transmitting the next block until informed 
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Fig. 4 — Data link protocol. 
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to do so by receipt of the correct acknowledgment from the slave in re- 
sponse to an ENQ (also used to obtain retransmission of garbled replies), 
whereas the RVI sequence requests that the master relinquish control 
of the line by sending the EOT sequence so that the slave may in turn 
transmit. 

3.2 Message, record, block, transmission definitions 

A message is defined as one heading and one text as supplied by any 
station in the network. In general, each stream of characters that contain 
messages terminates with an end-of-message (EOM) character which is 
immediately followed by a Longitudinal Redundancy Check (lrc) 
character. 

A record is defined as an entity ending with ITB as the EOM character 
or with ETB or ETX when it is the last record in the block. A message is 
normally one record but may span multiple records dependent on 
CSC-selected message-flow options. 

A block is one or more records to which an acknowledgment must be 
sent. Each block ends in either ETB or ETX followed immediately by an 
LRC character. Put another way, a block is the entity to which an ac- 
knowledgment is sent and a record is a member of a block. 

A transmission consists of a single connection procedure, is followed 
by the transmission of one or more blocks, and is then concluded by a 
single termination procedure. The last block, as sent by TNS, uses ETX 
as the EOM character, whereas all previous blocks end in the ETB char- 
acter. Thus, receipt of ITB, ETB, or ETX can be used by the CSC to define 
the position of a record within the transmission as well as to delimit the 
record. 

3.3 Data link protocol specification 

This section gives a specification of the data link protocol procedures 
that were described in general in Section 3.1. These procedures are in 
accordance with ANSI standard, X3.28-1971, 4 subcategories 2.3 and B.2 
with enhancements and capabilities that make them compatible with 
Binary Synchronous Communication (BSC) procedures as used by the 
majority of computer systems today. 

The data link protocol consists of a point-to-point contention proce- 
dure for nontransparent data in a nonconversational mode. Two pro- 
tocols are offered: Class I and Class II. Both recognize the WACK se- 
quence and also the RVI sequence as positive acknowledgments, but 
neither transmits RVI. The RVI sequence is a request from the slave 
station for the master station to stop transmitting. This allows the slave 
station to interrupt the master station and transmit a high priority 
message. The WACK sequence is a request from the slave station for the 
master to delay transmitting a new block. This is normally used when 
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the slave station has no more buffer space for new blocks. The WACK 
sequence is only transmitted by TNS in Class II. 

The Class I protocol is a basic BSC procedure widely supported within 
the computer industry. The Class II protocol has been enhanced to 
support a fuller feature data link protocol procedure. The resultant 
choice between protocols increases the compatibility with existing 
teleprocessing monitors. Both protocols yield performance which is 
dependent on the choice of options, as described later in this paper. 

3.4 Message format specification 

A message is defined independently of records or blocks and is defined 
to consist of one of each of the following parts, as shown at the top of Fig. 
5. The first part is a prefix of up to eight characters which may be in- 
cluded in every message from or to TNS and immediately follows the SOH 
character. Following the prefix, a Bell System specified heading must 
be provided by the originating station, as discussed below. 

Immediately following the heading and preceded by STX is a text field 
provided entirely by the originating station and transparent to the 
transaction network within the following constraints: 
(i) No data link control characters may be included. 
(ii) The text length is 128 characters or less. 

Preceding the EOM character, a suffix field consisting of one character 
may be combined with the EOM character in every message from and to 
TNS. Immediately following the EOM character, an LRC character must 
be included for error detection. 

All blocks are preceded by a synchronization pattern (shown as in 
Fig. 5) that consists of a leading pad character of alternating ones and 
zeros followed by at least two SYN characters. Also, all blocks end with 
a trailing pad character consisting of eight binary ones. 

While the text is composed solely by the originating station, the 
heading is specified by TNS. 

The heading format follows the proposed ANSI standard for heading 
formats. The two-character Heading Item Indicator 8 (Hll) identifies 
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which of the allowable fields are present. The one-byte sequence number 
subfield of the heading consists of an entry which is incremented by one 
on each successive message transmitted per data link by TNS. For a 
message transmitted from the CSC to TNS, this field may be omitted with 
the appropriate alteration of HII or may be stuffed with a space character 
if the field is not to be used. If a sequence number is included in messages 
sent to TNS, TNS will check to make sure that, on a given line, no two 
successive messages begin with the same sequence number. If they do, 
the second one will be returned with a message status report. 

The message status subfield consists of two characters and contains 
information only from TNS to the CSC, as will be seen in Section V. Thus 
the subfield must either be omitted on messages from the CSC, or stuffed 
with ASCII spaces or the normal status, all ASCII zeros. 

The calling and called number subfields are seven characters in length 
and contain the routing information. 

The station identifier subfield is used by TNS for screening as dis- 
cussed in Section 2.3 and may also be used by the CSCs to identify the 
type of station or calling party. 

IV. SPECIFICATION OPTIONS 

Options are available within these specifications to accommodate the 

varying degrees of capabilities and requirements of each CSC to do the 

following: 

(i ) Control what TNS may send to the CSC. 

(ii) Specify what the CSC will send to TNS. 
The major options consists of: 

(i ) Data link protocol options to provide additional line efficiency and 
teleprocessing monitor compatibilities. 

(ii) Message format options which allow the replacement of all Bell 
System-specified control characters in the heading by an optional 
set of characters which lie outside the ASCII control character set; 
and also prefixes and suffixes which are intended to aid in de- 
blocking and transaction handling. 

{Hi) Message flow options to comply with teleprocessing monitor 
characteristics which in turn specify maximum characters per 
record, maximum characters per block, maximum records per block, 
and maximum number of blocks per transmission. 

In addition to the above, the previously mentioned options determine 

the classes of service to be supported by the CSCs and also the network 

configurations such as line group specifications and alternate delivery 

points. 

3464 THE BELL SYSTEM TECHNICAL JOURNAL, DECEMBER 1978 



4. 1 Data link protocol options 

Several options are available to enhance the data link protocol (DLP). 
The first is a one- or three-second post-EOT delay for TNS which should 
not be confused with the primary/secondary designation. This post-EOT 
delay only applies immediately after relinquishing the line and before 
bidding anew. Choosing 1 second allows TNS to speed message transfers 
in the absence of messages from the CSC. The choice of 3 seconds gives 
the CSC a larger window in which to bid for the line uncontested, after 
the transmission of EOT by TNS. 

The second option is the choice of Class I or Class II protocols. The 
CSC chooses this option to best fit its existing software configuration. 

The last data link protocol option is the primary /secondary designa- 
tion in the case of simultaneous line bids. This option applies only to 
Class II protocols, since Class I protocols mandate that TNS be the pri- 
mary. 

4.2 Message format options 

The message format options provide considerable flexibility in ac- 
commodating existing CSC procedures. Referring to Figs. 6 and 7, these 
include: 

(i) Use of optional, noncontrol character heading subfield separa- 
tors. 
{ii) SOH deleted on the second and successive records in a block (a bsc 

option). 
(Hi) CSC use of optional sequence number and message status subfields 
to TNS. 

(iv) Prefixes for transaction identification and device codes. 

(u) Suffixes to aid in deblocking. 

(vi) Transmission end record to provide end-of-job indication. 
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Fig. 6 — Message format options. 
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Fig. 7 — Message format options (cont'd). 

4.3 Message flow options 

A set of options are offered to alter message flow which range from 
simplified message transfers to very efficient data link usage. 

The basic requirements are: the messages must be confined within 
a single block, no record should contain characters for more than one 
message, and the records should be inherently of variable length up to 
a maximum. 

The options are: 
(i) Maximum number of characters per record (F\) to and/or from 
TNS. If less than the maximum message length is selected, the 
message suffix must also be included to identify continuation rec- 
ords. 
(«) Maximum number of characters per block (F 2 ) from TNS. 
(Hi) Maximum number of records per block {Fa) from TNS. 
(iu) Maximum number of blocks per transmission (F 4 ) from TNS. 

4.4 Examples of option choice 

The two examples in Figs. 8 and 9 show the range of effect of the var- 
ious messages flow options. 

In Fig. 8, Fi has been chosen to be the maximum and F 3 and F 4 to be 
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Fig. 9 — Message flow — example 2. 

1. Note that specifying the characters per record to be the maximum and 
records per block to be 1 makes F 2 , the characters per block, automati- 
cally redundant and equal to M, the maximum characters per mes- 
sage. 

The effect of these choices is that TNS will send only one message at 
a time. Thus if the return message is ready for transmission before the 
post-EOT delay of 3 seconds (or 1 second) elapsed, one then gets a rela- 
tively straightforward but inefficient inquiry/response-type flow on the 
line. 

Since there is only one block per transmission, no suffix is required. 
This choice may in fact be appropriate when traffic requirements are 
very low or when the teleprocessing monitor can handle only one inquiry 
and response pair at a time. 

By contrast, Fig. 9 shows the most efficient line utilization where F x 
through F 4 are set to the maximum, reducing the number of acknowl- 
edgments and line turnarounds. 

Notice that the prefix and suffix have also been eliminated by the CSC, 
reducing the character overhead on the line. 

V. MESSAGE STATUS AND SERVICE FACILITIES 

The remaining major features of TNS are the message status reports 
and the service facilities alluded to previously. These features provide 
the CSC with considerable control over the data links and error condi- 
tions. The implementation of these features is designed so that a CSC 
need do little (e.g., not take advantage of all these extra features) or, as 
conditions warrant, may take full advantage of these capabilities. 

5.1 Message status reports 

Any message that encounters telephone company or customer 
equipment irregularities not covered by the data link protocols will be 
delivered to the called station, as is possible, or returned to the origi- 
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nating station. A report of the irregularity encountered is always inserted 
in the message status subfield of the heading as previously defined. The 
report is of the form X and Y, where X and Y are ASCII digits from to 
9. 

A class structure has been set up in the same order in which errors 
would be detected by TNS. The first class, Class I, consists of reception 
errors, or errors upon receipt of the message from the station not covered 
by the data link protocol. The second class, Class II, consists of routing 
errors as detected by TNS in attempting to route the message to the called 
party. Class III consists of forward path errors which prohibit the de- 
livery of the message. For Classes I, II, and III, the message will always 
be sent back to the originator. 

Class IV also consists of forwarding irregularities, where in this case 
the error does not prevent the message from being sent forward. And 
finally, in the great majority of the cases, Class applies to normal 
message transfers. 

The message status reports which will be seen in messages delivered 
to the CSC are shown in Fig. 10. Since most of the message status reports 
are self-explanatory, this paper will briefly highlight a few of the ir- 
regularities that will be reported. For example, "heading format error," 
or XY = 1,0, means that a required heading entry is missing in the 
heading field. One point to note, however, is that, if no heading can be 
found, the message will be dropped as an extraneous data stream not 
intended for message transfers. 

CLASS I - IRREGULARITIES ENCOUNTERED UPON TRANSMISSION TO THE TN. 

(X, Y) 

(1,0) HEADING FORMAT ERROR 

(1, 1) MAXIMUM TEXT LENGTH EXCEEDED 

(1.2) IMPROPER USE OF CHARACTERS 

(1.4) PROTOCOL ERROR 

(1.5) INVALID CALLING STATION 

CLASS II - IRREGULARITIES ENCOUNTERED UPON TN ROUTING. 

(X, Y| 

(3,0) NO SUCH NUMBER 

(3, 1) NUMBER CHANGED 

(3, 2) IMPROPER CLASS OF SERVICE CHARACTER 

(3.3) INVALID CALLED NUMBER 

(3.4) INVALID CALLING STATION TYPE 

CLASS III - IRREGULARITIES WHICH PREVENT MESSAGE FORWARDING 
FROMTN. 

(X, Y) 

(5.0) CALLED STATION UNAVAILABLE 

(5.1) CALLED STATION QUEUE OVERFLOW 

(5.2) UNANTICIPATED RESPONSE 

(5.3) TN NETWORK TROUBLE 

(5.4) INVALID CALLED STATION TYPE 
(5, 5) NO SUCH VOICE PHRASE 

(5, 6) SERVICE MESSAGE CANNOT BE PROCESSED 
(5,7) INCOMPLETE TRANSMISSION 

CLASS QZ - IRREGULARITIES ENCOUNTERED UPON FORWARDING MESSAGE 

(X, Y) 

(7,0) POSSIBLE DUPLICATE MESSAGE 

Fig. 10 — Synchronous message status reports. 
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Another example, "called station unavailable" with XY = 5,0, is nec- 
essarily a broad category encompassing all accidental or intentional 
failures of the called station to respond correctly to the delivery of 
messages. 

Only one status in Class IV applies, namely, possible duplicate mes- 
sage. This will be appended whenever TNS is unsure whether the message 
was previously delivered. 

5.2 Service facility — service messages 

Service facilities consist of instructions passed between TNS and any 
user station. As contrasted to a data message passed between terminals, 
telephones, and CSCs, a service message is a message either originated 
by or addressed to TNS and therefore includes the TNS station identifi- 
cation number in the heading of the form NXX-0999. 

There are two types of service messages. A request service message 
contains one or more requests for service actions and an acknowledgment 
service message contains one or more acknowledgments which are re- 
ports, affirmations', or denials of the requests. 

Service messages may initiate actions only for the line group on which 
they are received and therefore, for appropriate coordination, all the lines 
within the line group must be handled by a single entity or CSC. 

TNS will accept service messages over any line in the group, but the 
CSC may specify one line as the Service Administration Facility (SAF) 
over which TNS will send all service messages. This is done by specifying 
a priority scheme for each line in the line group which TNS will follow, 
as any line or lines in the line group become unavailable for use. This 
priority applies to both request and acknowledgment service messages, 
but not to reflection service messages, as will be seen. 

5.2. 1 Line and line group states 

A major usage of service messages arises from the fact that a line or 
line group can be in any one of several states, as shown in Fig. 11, each 
of which defines its capability. Service messages are used to set or report 
these states. While TNS will change states only upon the discovery or 
correction of failures, CSCs may implement state changes, if desired, to 
accommodate their own operational procedures. 

State 1, the active state, may only be set by the CSC and allows all 
message transfers. This is the normal state for a line or a line group. 

State 2, the active/CSC data only (ADO) state, can be set by either TNS 
or the CSC allowing data messages only from the CSC and service mes- 
sages in both directions. This may be considered as a standby state and, 
upon recovery from failures, TNS will always set state 2 and never 
state 1. 

State 3, the out-of-service far-end removed (OFER) state, may be set 
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SERVICE 

MESSAGE 
TYPE SEQUENCE TYPE FIELD 

FIELD NUMBER CODE STATE LINE NUMBER SEPATATOR 



Xi X2X20X^X5Ag 



• TYPE FIELD (0<t<9) IDENTIFIES THE BASIC TYPE OF THE SERVICE MESSAGE. 

• SERVICE MESSAGE SEQUENCE NUMBER (0<t<9) COORDINATES REQUESTS AND 

ACKNOWLEDGEMENTS. 

• INDIVIDUAL REQUESTS AND ACKNOWLEDGEMENTS MAY CONTAIN THE FOLLOWING 

TEXT FIELDS; 

• THE TYPE CODE (00<TC<99) IDENTIFIES THE TYPE OF REQUESTOR 
ACKNOWLEDGEMENT. 

• THE STATE (1<K<6) IDENTIFIES THE STATE REQUESTED OR REPORTED. 

• THE LINE NUMBER, IN LINE RELATED SERVICE MESSAGES, IDENTIFIES 
THE LINE. WITHIN THE LINE GROUP. ON WHICH ACTION IS TAKEN. 

• THE FIELD SEPARATOR, "+", DELIMITS INDIVIDUAL REQUESTS OR 
ACKNOWLEDGEMENTS. 

• ALTERNATIVELY, TEXT OF REFLECTION SERVICE MESSAGES APPEARS 
AFTER TC. 

Fig. 11 — Service message request and acknowledgment format. 

only by the CSC which then prevents all message transfers except for 
request service messages from the CSC and their accompanying ac- 
knowledgment service messages from TNS. 

State 4, the out-of-service far-end test (OFET) state, may only be set 
by the CSC and requests that TNS test its synchronous port hardware. 
No message transfers are possible and, upon successful completion of 
the test, TNS will set either state 2 or, upon failure, state 5. 

State 5 is the out-of-service other (00) state, which means that the TNS 
synchronous port hardware has failed. 

State 6 is the unavailable state for a line that has not yet been put into 
service. 

The relationship between the group state and the line states is as 
follows: Ordinarily, the group state will follow the highest line state 
within the group, where state 1 is considered to be the highest of the 
states. The group may never assume a state greater than the highest line 
state. For example, if there are three lines in a group and two lines are 
in state 1 and one line is in state 4, the group will normally be in state 
1. 

The CSC, however, may purposely put the group state to a lower state, 
thus not requiring the setting of each of the individual line states to ac- 
complish a service objective of its own. Therefore, if a line has a state 
higher than the group state, the group state in effect determines the 
operational status of that line. For example, if there are three lines in 
the group and the lines have states of 1, 2, and 3 and the group has a state 
of 3, each line will effectively be in state 3. However, when the group state 
is changed back again, the lines will return to their original states. 
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The TNS and the CSC must both keep a state table for each line and 
the line group, with the TNS defined to have the master state table. 

5.2.2 Service message protocol 

To accomplish the transfer of service messages, a simple end-to-end 
service message protocol must be obeyed. 

For each request put out by either station, there must be an ac- 
knowledgment. Only one request service message may be outstanding 
on a group at any given time from either TNS or the CSC, although, as will 
be seen in ertain cases, a request or acknowledgment service message 
may contain multiple requests or acknowledgments. 

Because of this, in the case of simultaneous requests, TNS is always 
considered to be the master since it will only originate service requests 
due to detected failures (or their correction), and therefore its request 
must be processed. In this case, the CSC request will be rejected and re- 
turned with a message status report. 

In case this service message protocol becomes violated, a halt/wait 
request will reset the protocol from either station by ordering all service 
message processing canceled; when received by the CSC, the CSC may 
not originate any new requests until it receives at least one additional 
request from TNS. This is required for the case where TNS is attempting 
to report a service failure and, because of a violation of this protocol, it 
cannot get a service request into the CSC. Therefore, it will halt all service 
message processing so that it will be able to send at least that one service 
request to the CSC. 

Finally, since multiple requests or acknowledgments may be contained 
in a single service message, in order to facilitate the CSC programming, 
an option exists to limit TNS to the transmission of only one request per 
request service message. 

TNS will always send acknowledgments in the form the requests were 
received. For example, N acknowledgments per service message will be 
sent back when N requests per service message were received. Therefore, 
if one request per service message was received, one acknowledgment 
per service message will be transmitted. 

5.2.3 Service message format 

Figure 11 shows the format of a service message excluding the heading 
which is identical to a data message. The first two characters in the text 
of a service message consist of a type field, t, and a sequence number, 
s, followed by the individual requests or acknowledgments. 

The type field, t, identifies the basic type of the service message. When 
grouped together, individual requests or acknowledgments must be of 
the same type. 

The next character is the service message sequence number (not to 
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be confused with the heading sequence number) which coordinates the 
requests and acknowledgments. The sequence number, s, must be ex- 
actly echoed in the acknowledgment to make sure that each request and 
acknowledgment may be paired by the request originating party. It is 
in the range from ASCII to 9 and is incremented by two modulo 10. It 
is even for TNS requests and odd for CSC requests. 

Each individual request or acknowledgment is identified by a type 
code (TC) which uniquely identifies the function to be performed. The 
remaining entries may consist first of a state K (between 1 and 6 as 
previously defined under the state definitions) which contains the state 
requested or reported. The second entry that may be present is a line 
number identifying the line on which the function is to be performed. 
Alternatively, for reflection requests the text to be reflected appears after 

TC. 

Finally, when multiple requests or acknowledgments are present 
within the same service message, the field separator ASCII "+" is used 
as a delimiter immediately following each individual request or ac- 
knowledgment. 

5.2.4 Service messages 

This section defines the individual service message requests and ac- 
knowledgments. The set state service messages consist of set group state 
or set line state requests, which are commands to put the group or line 
into a specified state. The accompanying acknowledgments report 
whether the requested action was taken and the resulting state. 

Similarly, the report state service messages consist of report group 
or report line requests seeking information as to what state the other 
station perceives to be true. The requests contain the state that the in- 
quiring station assumes to be true. Thus, the acknowledgment contains 
the receiving station's perception of state. 

The Halt/Wait request/acknowledgment service messages carry out 
the actions described in Section 5.2.2. 

While the above service messages follow the priority scheme of the 
SAF, the reflection request service messages may be transmitted over 
any line. The associated acknowledgments must be returned on the same 
line over which the request was received. The reflection service messages 
are requests to provide a predetermined echo of the original transmis- 
sion. They are intended to provide a testing capability both for new in- 
stallation testing of software and hardware by the CSC and also as an 
operational test by both TNS and the CSC. 

The simplest reflection request is for the return of the accompanying 
text. Other reflection requests produce single or multiple messages in 
one or two blocks as the echo subject to the constraints of Sections 4.2 
and 4.3. Also, reflection requests are defined to allow the testing of 
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input/output buffer sizes and to allow the acknowledgment to appear 
as an inquiry from a customer station. 

5.2.5 Summary of service message capabilities 

The service messages provide the CSC with the capability of exercising 
considerable control over the interface. This includes, in addition to the 
normal failure recovery procedures, the capability to fully test and 
reconfigure the local network due to operational requirements. 

5.3 Service facility — station identifier subfield 

The remaining service facility feature is the station identifier subfield 
in the message heading of messages from the CSC to terminals; that is 
to say, response messages. Whereas service messages do not relate to a 
specific data message, the station identifier service facility is used to 
choose operational procedures to be followed by TNS for a particular 
message. 

This service facility is generally used for dial-in telephones, for the 
following actions: 
(i) Voice only response. 
(ii) Key answer tone response for 1.5 seconds with no accompanying 

voice message. 
{Hi) Keyed answer tone for 3 seconds followed by a voice message. 
(iv) FSK response for dial-in telephones. 

(u) CSC specified disconnect of the telephone from the dial-in port. 
{ui) Finally, if no instructions are required, as for example, if the mes- 
sage is destined to a polled terminal, the CSC inserts the null field 
entries of ASCII "space space." 

VI. TEST INSTALLATION 

To verify the procedures of the interface specifications, a test con- 
figuration was installed on the Bell Laboratories' IBM 370/168 at 
Holmdel, N.J. The software configuration is shown in Fig. 2. The task 
consisted of writing Cobol programs to transfer messages with the TNS 
message switch. 

The approach taken was to write processing programs which were 
independent of the originating station and had a preprocessor and 
postprocessor to handle any station dependencies of the message text. 
It required less than 150 lines of Cobol code to enqueue and dequeue the 
inquiry and response messages. 

A service message routine was written to handle normal service mes- 
sage processing (e.g., acknowledge TNS requests and activate lines) and 
consisted of some 200 Cobol statements. Message status reports were 
simply logged and used as a debugging tool for the test system. 
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